The three principal areas on which development issues have been submitted to Developer Technical Support, aside from bug reports and enhancement requests, have been:
• card initialization (CARD_READY)
• multifunction card implementation
• application use of PC Card modems
Initialization
The most common issue raised by developers creating a client for an IO card is “After I call CSRequestWindow, why can’t I see my registers?” Rather than spend a long winded moment trying to unravel the proper sequence of events for this operation, we have tried to supply an explicit example of how to do this for an ethernet card in the sample PC Card client which is general enough to use as a skeleton for all IO cards.
The rough methodology is to use CSRequestWindow for an Attribute window and pull desired information for configuration from your card’s attribute space. Then you CSRequestWindow for on IO window, configure it, and lock in the configuration by calling CSRequestConfiguration. IO windows on the Macintosh are memory mapped; you cannot access registers in IO windows until you call CSRequestConfiguration. The memory mapping of IO windows on the Macintosh is a fundamental difference between PC Card implementations on Macintosh vs other systems.
Please see the ConfigureMyCard() function in the example source code.
Creating Multifunction Cards
The development of Multifunction PC Cards is not explicitly treated in the PCMCIA v2.1 specification upon which PC Card Manager v2.0 is based. The basic idea is that your card client must configure and support all the functionality of your card: the Apple supplied modem client cannot be used to operate the modem portion of your card while your client runs the ethernet or whatever other functionality the card supplies.
Please see the section in the reference documentation “Developing PC Card SW for Macintosh” on multifunction card development. Developer Technical Support will work to assist you on these issues if you have any difficulties.
Modem/Serial Access for Applications
Many applications make the assumption that all Macintosh cpus have two serial ports, named “Modem Port” and “Printer Port”, that all serial port access utilizes the two driver pairs, “.AOut/.AIn” and “.BOut/.BIn”, and that the reference numbers for all serial port access are static constants that never change.
These are incorrect assumptions. Macintosh cpus can have one or two built-in serial ports, internal modems, add-in serial expansion cards, and now PC Card serial devices in bewildering array. Applications should never make assumptions about the availability of these system resources and hard code them.
The correct way to find out about serial resources of a given cpu configuration is to use the Communications Resource Manager, documented in “Inside the Macintosh Communications Toolbox.” There are datastructures and functions by means of which a serial device, it’s name and it’s driver names, plus its identifying icon are registered with the OS after the drivers are installed, de-register it when it’s no longer available, and acquired by applications that might want to use them.
Using this mechanism has ramifications important to your development, both from the point of view of a card client implementation and from the application development perspective.
If you are creating a PC Card modem, the Apple-supplied modem client will register your card as a serial device according to information available when it is inserted, and will de-register it when the card is ejected. In the case of a multifunction card the Apple modem client is not handling the interaction so you must register and deregister your serial device with the CRM as appropriate. Your serial driver should comply with the Macintosh Serial Driver API. It’s also important that your software be able to handle name collisions in CRM registration.
If you are writing an application which uses serial resources and modems, instead of making the assumption of the Printer and Modem port serial model, you should use the CRM to determine which serial resources are available for the user to configure and present a selection component in your software for the user. You cannot make assumptions about what the names of ports will be, nor what the driver names will be, and you must be able to handle errors that happen when a particular piece of hardware is removed from a configuration, or it’s location is changed. In other words, you must be prepared for a dynamic hardware/driver environment to give your user the best possible user experience.
The Apple Modem Tool and the Serial Tool, used by applications in conjunction with the Connection Manager, are dependent upon these same CRM-registered entities for serial hardware access.
Included in this PC Card SDK is some brief sample code which illustrates the basics of obtaining port information; see the “CRM Sample” folder. It is by no means complete but we hope that it will be useful for application developers.
Please see the appropriate section in “Inside the Macintosh Communications Toolbox” for complete documentation on the Communications Resouce Manager, and take a look at the CRM Sample code that we’ve provided.
Where to go for development help
As always, if you have any development problems, bug reports or other development issues to discuss, please send a message to the Developer Support Center (AppleLink: DEVSUPPORT, Internet: devsupport@applelink.apple.com) and we will be happy to assist you in any way that we can.
